A file system is a method for storing and organizing computer files and the data the files contain, on storage (e.g., on disk). Most file systems use an underlying non-volatile data storage device on which files are persisted. A typical storage device provides access to an array of fixed-size blocks, sometimes called sectors, which are generally 512 bytes each. The file system software is responsible for organizing these sectors into files and directories. The file system also keeps track of which sectors belong to which file and which sectors are not being used. Traditional file systems offer facilities to open, create, move and delete both files and directories.
File systems typically have data structures which associate a file name with a location on disk where the contents of the file is stored. Usually this is done by connecting the file name to an index into a file allocation table of some sort, such as the FAT in an MS-DOS file system, or an inode in a UNIX-like file system. File system directories may be flat, or may allow hierarchies. In hierarchical directories, each directory may include one or more sub-directories. In some file systems, file names are structured, with special syntax for filename extensions and version numbers. In others, file names are simple strings, and per-file metadata is stored elsewhere.
In many file systems, a file can be accessed by more than one identifier. For example, some older operating systems, (and thus older applications) only supported 8.3 file names. More current operating systems may continue to support the 8.3 file names. For example, in some older Microsoft operating systems, the “Documents and Settings” folder may have been accessed by using a name such as “DOCUME˜1” (the 8.3 file name) while newer systems can either use “Documents and Settings” or “DOCUME˜1” to access that folder. The “DOCUME˜1” reference is a hard link to the “Documents and Settings” folder, meaning that “DOCUME˜1” is a separate file system entity, and points to the same physical location as the “Documents and Setting” hard link. The same file can be accessed via either name. Additionally, the same file may be able to be opened using its file identifier or file ID, which in Microsoft operating systems is a numeric value frequently referred to as FileID. FileID is an alias because it is not a separate file system entity, but instead is another way to access the physical location of the folder.
In most current commercial operating systems an application shares file system namespaces with other applications running on the machine. The application's access to files is mediated by a security mechanism that attaches an Access Control List (ACL) to each named file. The ACL relates a user to a set of access rights for that particular resource. For example, the ACL for a particular resource may specify that user 1 is allowed read-write access to file1 and that user 2 is allowed read-only access to file1. Because of the widespread use of ACL-based permission controls, multiple applications are often allowed to share files. Access to the files is based on privileges associated with the identity of the person running the application or process rather than being based on the needs and characteristics of the application itself. This approach can be problematic. For example, a user may have broad access privileges (e.g., administrator status) because some of the programs he runs need that level of access. For example, because program_1 run by user_1 needs access to files one to ten, user_1's access privileges must permit him to access files one to ten. Suppose program_2 only needs access to files one and two. When user_1 runs program_2, program_2 will nevertheless have access to files one to ten, because user_1's privileges allow access to files one to ten. Thus, because file system operations are based on ACL-based permission controls, in general, the file system name space can be and generally is more or less global to all the processes launched by user_1 running on the machine. ACL-based permission controls lead to a number of problems including: a program could waste processing time handling things it should not consider, the presence of a new file that the program is not expecting might cause the program to operate incorrectly, different programs may write or modify the same file, causing interference and so on. This problem is exacerbated because not all programs have the same level of trustworthiness. Program 2 may not be as trustworthy as program_1 but since the user's privileges allow him to access files one to ten, program_2 has access to files one to ten and may maliciously modify them. In addition, there may be occasions when it is desirable to provide different programs different files even though the programs use the same name for the file. Finally, different programs may use the same name but mean different files. Hence, there is a need for better control of shared resources than that which can easily be obtained using ACLs and privileges.